Find the actual failure
- Open DevTools on the iframe lab (right-click → Inspect). Enable Preserve log in Network and Console. Open the requested site again.
- In Network, select the frame's document request, including redirects. Review the status, Response Headers and Request Headers. “Provisional headers” do not prove that headers were sent. For local testing, compare the server's echo output.
- In Console, look for “Refused to frame” or “Refused to display”. Record the directive and URL. A 200 response and an iframe load event do not prove that a page rendered.
- Open the same URL directly and compare requests, cookies and Console errors. The iframe is a nested browsing context; a normal tab is a top-level context even with modified headers.
Embedding policies
X-Frame-Options: DENY refuses embedding. SAMEORIGIN requires a matching origin; this extension has its own chrome-extension origin. CSP frame-ancestors restricts which ancestors may embed the response and may consider the entire ancestor chain.
CSP frame-src belongs to the embedding document and restricts where its frames can navigate. This lab allows HTTP(S) frames in its own extension CSP. A remote page may impose another frame-src policy on its own nested frames. Check which document emitted the message.
These policies are different from a site's own JavaScript iframe check, login flow, anti-abuse check, sandbox dependency or server-side validation. Use evidence from Console and Network; do not assume Referer is the cause. This tool does not remove X-Frame-Options or CSP.
CORS, cookies and authentication
CORS concerns script access to cross-origin responses, not generally navigation into an iframe. Changing Origin does not change the browser's security origin or authorize CORS access. SameSite cookies, third-party cookie restrictions and partitioned storage can change login behavior in a frame. Inspect the Issues panel and the Cookies tab for blocked cookie explanations.
Changing a header does not bypass authentication or access controls. Use a development endpoint you control and configure its legitimate embedding, cookie and CORS policies.
Header rules and Chrome limits
Grant destination access from the rule editor. Initiator access can also be required for cross-origin subresources; create a disabled rule for that origin and save it to grant access without modifying its requests. Use the all-sites scope only for a deliberate browser-wide test. Chrome internal pages, the Chrome Web Store, other extensions, cached responses and service-worker-generated responses may not be affected. Reload with Network → Disable cache and test your server directly.
Rules match exact HTTP(S) origins, including ports; not paths or subdomains. Highest listed matching rule wins for the same header. Changes affect new requests. Removing a permission in Chrome prevents modifications at that site even if the master switch remains on.
User-Agent changes only the HTTP header, not navigator.userAgent or Client Hints. Referer and Origin are set requests to Chrome, not guarantees of the final wire value. Chrome may reject a rule or constrain headers. If installation fails, the previous rule set remains; the UI reports the error. Inspect the actual sent request on your Chrome version.
This tool conservatively rejects Host, transport headers, Cookie, Authorization, Sec-* and Proxy-*. This is a product safety policy, not a claim that all these are universally forbidden by DNR. Custom printable headers are allowed, subject to Chrome validation and server behavior.
Privacy, permissions and reset
Only storage and declarativeNetRequestWithHostAccess are mandatory. Optional HTTP(S) host access is requested on Save. No tabs permission is needed just to create a tab. There are no content scripts, remote scripts, network logging or telemetry. Sites opened in the iframe naturally contact their own servers. Rules and their values stay in chrome.storage.local, unencrypted; do not store secrets. Restore defaults deletes rules and disables the master switch. Use Revoke all site access to remove previously granted host permissions.
All interface text is English and isolated in UI files for future localization. No automatic language switching is implemented.
References: Chrome declarativeNetRequest · Chrome permissions